In the field of packet based communication, it is often desirable to inform the sender of packets in a communication of a congestion condition along the communication path, such that the sender can appropriately adjust its flow control. An indirect (implicit) way of doing this is to drop packets and rely on the communication end points noticing and correctly interpreting this loss of packets. A direct (explicit) way of doing this is to send an explicit congestion indication to the communication end points, i.e. explicit information that informs of the presence or threat of congestion.
For example, packet marking is typically used by Internet routers to alert applications that congestion has occurred somewhere along the transmission path. The application or transport layer can then reduce the transmission rate to reduce the congestion. The packet marking for IP (Internet Protocol) is generally called Explicit Congestion Notification (ECN) and is defined in Request for Comments (RFC) 3168. Such packet marking is generally a complementary congestion control method to more robust packet dropping.
For ECN capable IP flows, the IP header indicates per packet the support for ECN. The actual packet marking is done in ECN capable IP routers by modifying the ECN field of the IP header to indicate congestion.
For nodes that are not directly accessing the IP header (i.e. for non-routers), this presents a problem, as it may not always be possible to observe or modify the encapsulated IP packet header. This situation occurs for example with MPLS (Multiprotocol Label Switching) or PPTP (Point-to-point tunneling protocol), and in general whenever ciphering or integrity protection is used and/or the modification of the IP header is impossible.
If nothing is done an implicit congestion notification will be provided by experienced packet drops, i.e. the receiver experiences packet losses and can take this as a sign of congestion. However, this is not acceptable for many applications (e.g., a video service would be stalled). In other words, it is often desirable to provide a form of explicit congestion notification, e.g. ECN as known in connection with IP.
One example for how to notify an application about increased risks for congestion in the network, before congestion happens, is to use ECN on the IP layer. The application in the receiver can use the received ECN indication as a trigger to inform the sender application to lower the packet rate and by that avoid packet losses. This can be achieved by using application layer signaling (e.g. the Real-Time Control Protocol (RTCP)). These principles are shown in FIG. 2 in relation to a mobile network consisting of a Radio Access Network (RAN) and Packet Switched Core Network (PS CN) parts. More specifically, an application 24 running on User Equipment (UE) 21, which also acts as a Mobile Station (MS) of a mobile communication system comprising a node 22 of a Radio Access Network and a node 23 of a Packet Switched Core Network, has established an end-to-end IP communication with another application 25 that runs on another terminal (not shown), such as e.g. another UE communicating with the mobile communication system. The control of the Access Stratum (AS) communication on the section (e.g. link) between the MS and the RAN can not access the IP packets, in contrast to the control of the Non-Access Stratum (NAS) on the section between the MS and the PS CN.
In current second generation (2G) and third generation (3G) systems (including the Long Term Evolution (LTE)) the link layer does not support packet marking at intermediate nodes. The marking is only possible at the UE and Gateway General Packet Radio Service Support Node (GGSN) (and System Architecture Evolution Gateway (SAE-GW)) nodes. For example, entity 22 of the RAN in FIG. 2 may not be able to ECN mark IP packets for lack of being able to access the IP header.
The problems related to packet marking are further shown in FIG. 3 in relation to the Packet Switched (PS) domain in GERAN (GSM EDGE Radio Access Network, where GSM stands for Global System for Mobile communications and EDGE for Enhanced Data Rates for GSM Evolution). Similar to the generic case of FIG. 2, an application 35 communicates with another application (not shown) via a protocol stacked network comprising an MS 31, a Base Station Subsystem (BSS) 32, a Serving GPRS Support Node (SGSN) 33 and a Gateway GPRS Support Node (GGSN) 34. The basic structure is known, such that a further explanation is not necessary. The involved abbreviations are as follows, as far as they have not yet been explained: SNDCP=Sub-Network Dependent Convergence Protocol; LLC=Logical Link Control; RLC=Radio Link Control; MAC=Medium Access Control; RF=Radio Frequency; BSSGP=Base Station Subsystem GPRS Protocol; L1=Layer 1; GTP=GPRS Tunneling Protocol; GTP-U=GPRS Tunneling Protocol for User Plane; UDP=User Datagram Protocol; L2=Layer 2; Um, Gb, Gn and Gi are known interfaces.
The Base Station Subsystem (BSS) 32 comprises a Base Station Controller (BSC) and a number of Base Transceiver Stations (BTS) and would be a good place to perform packet marking, for example based on the radio conditions and the different packet queues in the downlink direction. The main problem in this case is that the LLC-protocol (Logical Link Control protocol) between the MS 31 and the SGSN 33 is normally operating in ciphered mode. This means that the BSS 32 has no way to perform packet marking in the IP packet header, as the IP packet is sent ciphered through the BSS 32.
Another example of the same problem is shown in FIG. 4, where the PS domain user plane is shown for a Generic Access Network (GAN). For simplicity, neither the application layer nor the GGSN is shown. The communication generically shown in FIG. 2 is embodied by an MS 41, a node 42 of a generic IP network, a GAN controller (GANC) 43 and an SGSN 44. Similar to the BSS in the case of FIG. 3, the GANC 43 is not able to perform packet marking as the LLC-layer between the MS 41 and the SGSN 44 is normally functioning in ciphered mode. The basic structure is known, such that a further explanation is not necessary. The involved abbreviations are as follows, as far as they have not yet been explained: GA-PSR=Generic Access Packet Switched Resources; IPSec=Internet Protocol Security; ESP=Encapsulating Security Payload.
The existing link layer mechanisms in GERAN, GAN, WCDMA (Wideband Code Division Multiple Access) and LTE do not support packet marking in those nodes which handle and/or control the link layer on the air interface to the MS, e.g. BSS/BSC, GANC, RNC or eNodeB (E-UTRAN NodeB where E-UTRAN stands for Evolved UTRAN and UTRAN stands for Universal Terrestrial Radio Access Network). In the GERAN and GAN cases, it is not even possible for these nodes to access the IP packet header for packet marking.